home *** CD-ROM | disk | FTP | other *** search
/ Chip 2007 January, February, March & April / Chip-Cover-CD-2007-04d.zip / 04d / Hity z okladki / Plus Firma / Plus Firma 5.5.1.msi / Binary.New_Binary3.6FC97963_2511_11D4_BB8A_00C04F20D375 / RCDATA / CABINET / relnt95.txt < prev    next >
Text File  |  1999-03-28  |  19KB  |  457 lines
  1. DCOM95 1.3
  2. Release Notes
  3. Last Modified: March 14, 1998
  4.  
  5. DCOM95 provides Distributed COM support for Microsoft« Windows« 95.
  6. The DCOM wire protocol transparently provides support for reliable, 
  7. secure, and efficient communication between Component Object 
  8. Model (COM) components such as ActiveX« controls, scripts, and 
  9. Java applets residing on different machines in a LAN, a WAN, or on 
  10. the Internet. With DCOM, your application can be distributed across 
  11. locations that make the most sense to your customer and to the 
  12. application.
  13.  
  14. For more in-depth information, see the DCOM Technical overview 
  15. available on the Microsoft COM home page, 
  16. http://www.microsoft.com/com/.
  17.  
  18. Contents
  19. ========
  20. I.   New Features since DCOM95 1.2
  21. II.  Bug Fixes since DCOM95 1.2
  22. III. Known Issues
  23. IV.  Differences from DCOM on Windows NT
  24. V.   Redistribution
  25. VI.  Support & Resources
  26. VII. File List
  27.  
  28. I. New Features since DCOM95 1.2
  29. --------------------------------
  30.  
  31. Support for VB6.0 Data Types
  32.  
  33. Visual Basic« 6.0 allows Visual Basic variants to contain user-
  34. defined data structures. DCOM95 now supports remoting of these 
  35. variants.
  36.  
  37. II. Bug Fixes since DCOM95 1.2
  38. ------------------------------
  39.  
  40. This section describes bugs fixed in DCOM95 1.3 that affected
  41. applications running on Windows 95 with DCOM95 1.2 installed.
  42.  
  43. File Monikers Support Additional Path Syntax
  44.  
  45. File monikers can now be created out of arguments of the form 
  46. <startdir><relativepath>, such as "C:\bug\bug\..\..\foo.jpg." In 
  47. DCOM95 1.1, only relative paths (e.g., "..\..\foo.jpg") or absolute 
  48. paths (e.g., "C:\foo.jpg") were permitted.
  49.  
  50. General Protection Fault When Oleaut32.dll Unloaded
  51.  
  52. In previous versions of DCOM95, a general protection fault occurred 
  53. when Oleaut32.dll was unloaded before a call to CoUninitialize. This 
  54. would most often occur when a VB application created a control 
  55. statically linked to Oleaut32.dll, and then freed the control prior
  56. to calling CoUninitialize. This no longer causes a general 
  57. protection fault in the latest release of DCOM95.
  58.  
  59. Visual Basic Type Marshaling and Unmarshaling
  60.  
  61. The marshalling and unmarshaling of certain Visual Basic data 
  62. types has been fixed. Array parameters with a size greater than 64K 
  63. are now allowed. Structures defined using aliases to the type are 
  64. now marshaled and unmarshaled correctly.
  65.  
  66. Atoms Being Deleted Too Many Times in OleUninitialize
  67.  
  68. This bug appeared in applications that call OleInitialize and 
  69. OleUninitialize multiple times. During initialization, OLE adds many 
  70. atoms for DDE RPC. If the atoms have already been added by 
  71. another thread, they are not added again. However, during 
  72. uninitialization, atoms were always deleted, and the handles were 
  73. not nullified. Therefore, the next time OleInitialize was called, the 
  74. old handles would still exist, even though the atoms were already 
  75. deleted, and OLE would not add them again. This led to all OLE 
  76. atoms being invalid after multiple calls to OleInitialize and 
  77. OleUninitialize. This problem has been fixed in this release of 
  78. DCOM95. 
  79.  
  80. ADO Servers Shut Down Properly
  81.  
  82. Active Data Objects (ADOs) use pointer monikers to start a server 
  83. process. Previous versions of DCOM95 contained a bug involving 
  84. pointer moniker reference counting, whereby pointer monikers were 
  85. created with an initial reference count of 1, rather than 0. 
  86. Therefore, the reference count of the pointer moniker would never 
  87. get to zero, and the pointer moniker would never be freed. As a 
  88. result, ADO servers were never shut down, even after the last 
  89. pointer to them had been released. This has been fixed in this 
  90. release of DCOM95.
  91.  
  92. CoCreateInstance Works with Own DNS Name
  93.  
  94. In previous versions of DCOM95, calling CoCreateInstance with the 
  95. fully qualified name of the local machine did not work. This has been fixed in 
  96. the current version of DCOM95, and CoCreateInstance now correctly 
  97. creates and instance on the local machine.
  98.  
  99. Slow Commit On Root Storage With Very Large Compound File
  100.  
  101. In previous versions of DCOM95, the commit time on a root storage 
  102. opened in STGM_TRANSACTED mode became very slow as the compound 
  103. file became very large (e.g. 400M). The internal page table 
  104. limits have been increased, and this is no longer a problem.
  105.  
  106. Exporting Objects From a Recreated MTA
  107.  
  108. In previous versions of DCOM95, a server could not export an 
  109. object from a Multi-Threaded Apartment (MTA) if this was not the 
  110. first time the MTA had been created in the process. This has been 
  111. fixed. Now, if a server creates an MTA, destroys it, and 
  112. subsequently recreates the MTA, objects will be able to be 
  113. exported from the MTA.
  114.  
  115. Multiple Instances Of Visual Basic 4 EXEs
  116.  
  117. In DCOM95 v1.1, if you started multiple instances of the same 
  118. Visual Basic 4 executable, then shut them down in any order but 
  119. LIFO (Last-In First-Out), the last exe would hang. This was also 
  120. true of E-Forms in Microsoft Exchange. This has been fixed in 
  121. the latest release of DCOM95. You may now shut down Visual 
  122. Basic 4 exes in any order.
  123.  
  124. Extended Characters in Visual Basic File Names
  125.  
  126. If you named a Visual Basic module or class using extended 
  127. characters for a given language, that file might not open on 
  128. machines configured for a different locale. This has been fixed.
  129.  
  130. Heap Memory Leak When Using IDataObject/IAdviseSink
  131.  
  132. There was a memory leak when using Uniform Data Transfer between 
  133. a data object on a local server that implements the IDataObject 
  134. interface and a client that implements IAdviseSink. When the 
  135. client used the STA model, every call would leak 32 bytes. This 
  136. problemmanifest itself as the server taking more and more time 
  137. to execute. The leak has been fixed.
  138.  
  139. III. Known Issues
  140. -----------------
  141.  
  142. Corel WordPerfect Suite 7: Installation Causes Invalid Page Fault
  143.  
  144. If you install Corel WordPerfect Suite 7 on a Windows 95 system 
  145. running DCOM95, you may get an invalid page fault in PfOd70.pfc 
  146. during installation. If this error appears, just close the error 
  147. message dialog box. Setup should continue successfully.
  148.  
  149. Microsoft Access95: Database Replication Does Not Work
  150.  
  151. If you try to replicate an Access database using Microsoft Access 
  152. 95 on machines with DCOM95 installed, you may get the following 
  153. error message: 
  154.  
  155. Microsoft Access cannot complete this operation because it 
  156. can't find or initialize the dynamic-link library Msjtrclr. 
  157.  
  158. This is a problem in Microsoft Access 95. You may work around this 
  159. issue by writing a program which uses the Access object model 
  160. rather than the replica tool, or by using the briefcase for replication. 
  161. Microsoft Access 97 is not affected by this issue. 
  162.  
  163. WordPerfect 
  164.  
  165. If you have a WordPerfect document containing an embedded 
  166. Corel spreadsheet and the spreadsheet contains another 
  167. embedded object (for example, a bitmap), you may get a warning 
  168. dialog saying youÆve lost the network connection when you close the 
  169. innermost object. There may be four or five such warnings. All 
  170. these warnings are benign. Just close them and continue.
  171.  
  172. Multiple-threaded apartment (MTA) clients that use BSTR 
  173. conversion routines may block DDE messages
  174.  
  175. Automation BSTR conversion routines (for example, BstrFromR4) 
  176. create hidden windows to facilitate the type conversion. These 
  177. windows do not service the Windows message queue. If such a 
  178. window is created from within an MTA client, DDE messages may 
  179. be blocked. The client thread has no obligation to service the 
  180. message queue under the MTA programming model. If it does not, 
  181. this top-level window causes global broadcast messages to block.
  182.  
  183. There are two ways to work around this situation. Either call the 
  184. BSTR conversion routines from within a single-threaded apartment 
  185. (STA) client, or make the clientÆs MTA thread behave like an 
  186. STA thread. (An STA thread must service the message queue.) If 
  187. the thread is blocking on a win32 handle, it must call the 
  188. MsgWaitForMultipleObjects function to simultaneously dispatch 
  189. Windows messages. 
  190.  
  191. DLL path names longer than 127 characters cause error
  192.  
  193. If you register a DLL with a path name of 128 characters or longer,
  194. the registration will succeed, but CoCreateInstance or CoGetClassObject
  195. will return an error (REGDB_E_CLASSNOTREG) when accessing an object
  196. supported by this DLL.
  197.  
  198. IV. Differences from DCOM on Windows NT
  199. ---------------------------------------
  200.  
  201. Security Capabilities of DCOM95
  202.  
  203. The core functionality and application programming interface (API) 
  204. for DCOM95 are identical in both Windows 95 and Windows NT 
  205. 4.0. However, certain capabilities related to security are different 
  206. because of the different security infrastructures of the operating 
  207. systems. Using the default security settings of the system is 
  208. recommended; it is also necessary to enable "user-level" security 
  209. on file-system shares. (See below.) 
  210.  
  211. The following services, which can be used to override default 
  212. security, are available: 
  213. *    CoInitializeSecurity 
  214. *    CoQueryAuthenticationService 
  215. *    CoQueryProxyBlanket 
  216. *    CoSetProxyBlanket 
  217. *    CoQueryClientBlanket 
  218. *    IClientSecurity Interface 
  219. *    IServerSecurity Interface 
  220.  
  221. However, certain capabilities that are part of DCOM for Windows 
  222. NT will not be available on Windows 95 because of differences 
  223. in the security infrastructure on Windows 95.
  224.  
  225. In particular, the lack of security functions in the Win32 API, such
  226. as the ability to create access control lists (ACLs), and the 
  227. AccessCheck function, as well as the lack of a security context 
  228. associated with thread and process tokens, should be taken into 
  229. account. Windows 95 does not natively support these functions or 
  230. constructs. Because of this, DCOM95 will not support impersonation
  231. (specifically, the CoImpersonateClient and CoRevertToSelf helper 
  232. functions over the IServerSecurity interface), which is based on 
  233. thread- and process-token security in Windows NT 4.0. Impersonation 
  234. is commonly used to automatically control access to restrictable 
  235. system resources such as the file system, other processes, and the 
  236. network. These resources are not restrictable on Windows 95. 
  237.  
  238. DCOM95 does, however, offer programmers various helper objects 
  239. to provide ACL and access-check functionality, which can be used 
  240. to explicitly control access by remote clients to both system and 
  241. user-defined resources or data. These helper objects are provided 
  242. by the system object CLSID_DCOMAccessControl, which implements the 
  243. IAccessControl interface.
  244.  
  245. IAccessControl should be used to manage security permissions 
  246. programmatically wherever portability between Windows 95 and 
  247. Windows NT is a concern. The CLSID_DCOMAccessControl object 
  248. is available in all releases of DCOM95 and in Windows NT 4.0 
  249. SP2 or later. For details about IAccessControl, see the Platform 
  250. SDK documentation.
  251.  
  252. Launch and Access Security 
  253.  
  254. Controlling who can launch server-class code is not supported in 
  255. DCOM95, because launching servers is not supported. 
  256. Servers/classes must already be running in order for remote clients 
  257. to connect to them and make use of their services. 
  258.  
  259. DCOM95 does support the ability to connect to already running 
  260. classes/servers. Access security is supported via the 
  261. \APPID\{.}\AccessPermissions registry key and adjusted via the 
  262. DCOMCNFG tool or during installation or setup of the server code. 
  263. Unauthenticated users will be able to use servers if you configure 
  264. the class to support unauthenticated connections (through static 
  265. configuration tools or dynamically via the CoInitializeSecurity 
  266. function). You can also build arbitrary ACLs to define which users 
  267. and groups can access specific services. 
  268.  
  269. Authentication Levels 
  270.  
  271. DCOM95 clients can make DCOM calls using any authentication 
  272. level. DCOM95 servers or clients receiving callbacks can accept 
  273. only DCOM calls using RPC_C_AUTHN_LEVEL_NONE or 
  274. RPC_C_AUTHN_LEVEL_CONNECT authentication levels.
  275.  
  276. Transports
  277.  
  278. DCOM95 supports only TCP connectivity. If you do not have the 
  279. TCP/IP protocol installed, DCOM95 will not be able to support 
  280. cross-machine COM. 
  281.  
  282. Registry Settings 
  283.  
  284. The following registry keys found under 
  285. HKEY_LOCAL_MACHINE\Software\Microsoft\OLE are established 
  286. by DCOM95: 
  287.  
  288. EnableDCOM (default value = "Y"). Enables DCOM on this machine. 
  289. When set to "N", the machine is prevented from connecting to or 
  290. activating objects on remote machines, and remote machines are 
  291. unable to connect to objects on the local machine. Setting this value 
  292. to "Y" enables either connectivity as a client to remote objects 
  293. (when EnableRemoteConnect='N', as explained below), or full 
  294. client/server connectivity (when EnableRemoteConnect='Y', as 
  295. explained below). 
  296.  
  297. EnableRemoteConnect (default value = "N"). Enables COM servers 
  298. to support remote clients. When this value is set to "Y", references 
  299. to interfaces on local objects can be passed to remote clients, and 
  300. remote clients are allowed to connect to running objects. When this 
  301. value is set to "N", this machine is allowed to connect to remote 
  302. objects but cannot act as a server: the machine is prevented from 
  303. connecting to running objects. 
  304.  
  305. In addition, the following registry key is found under 
  306. HKEY_CLASSES_ROOT\CLSID: 
  307.  
  308. {bdc67890-4fc0-11d0-a805-00aa006d2ea4}\InstalledVersion. 
  309. Contains the version number of DCOM95 in the format "a,b,c,d". 
  310. This value can be used by Internet Component Download to 
  311. determine whether DCOM95 is installed. This value is added to the 
  312. registry during setup and should not be modified. 
  313.  
  314. Using Windows 95 as a remote server host
  315.  
  316. Windows 95 can be a remote server host, with the following 
  317. caveats:
  318. *    There is no launch capability. The server process must be 
  319.     already running for a client to connect to it.
  320. *    If secure connections are needed, the server (and in the case
  321.     of callbacks, the client) must have user-level access control
  322.     with the name of a security provider set. 
  323. *    The registry value "EnableRemoteConnect" must be set to "Y".
  324.  
  325. DCOM95 has been tested most extensively using the Windows NT 
  326. Domain security provider. You may encounter problems using other 
  327. security providers.
  328.  
  329. To establish user-level access control, you must have Filesec.vxd 
  330. installed. This file is generally installed on Windows 95 machines 
  331. when you install file and print sharing.
  332.  
  333. To enable user-level access control, open the Network dialog box in 
  334. Control Panel, click the Access Control tab, check the box marked 
  335. User-level Access Control, and enter the name of your security 
  336. domain. This may affect the way you currently share directories on 
  337. the network from your computer; see the online documentation for 
  338. details. If you do not have an Access Control tab in your network 
  339. configuration control panel, you need to install a network client 
  340. service. Click the Network clients, setting up entry in the online 
  341. help index for information on installing a network client.
  342.  
  343. V. Redistribution
  344. -----------------
  345.  
  346. For information about redistributing DCOM95, please review the
  347. redistribution guidelines contained in the end-user license
  348. agreement (license.txt).
  349.  
  350. If you elect to redistribute DCOM95, you should include the files
  351. DCOM95.EXE and optionally DCM95CFG.EXE on your distribution media.
  352. You should run these self-extracting executables from your setup
  353. program. These executables will install the correct files only if
  354. a more recent version is not already installed. They write the
  355. correct registry entries required by DCOM95. They do not install
  356. anything on Windows NT.
  357.  
  358. By default, DCOM95.EXE and DCM95CFG.EXE display a EULA and other
  359. prompts to the user. DCOM95.EXE prompts the user to reboot the
  360. system on completion. If you run either executable from your setup
  361. program, you may elect to run the self-extracting executables in
  362. "silent" mode. You must prompt the user to reboot the system when
  363. your setup program exits if DCOM95 has been installed.
  364.  
  365. To run either DCOM95.EXE or DCM95CFG.EXE in silent mode, use the command line:
  366.    [exe-name] /r:n /q:a
  367.  
  368. VI. Support & Resources
  369. -----------------------
  370.  
  371. Paid Support
  372.  
  373. DCOM95 application development is supported by Microsoft 
  374. Technical Support. You can ask questions through your Premier 
  375. Level support contract. You can also ask questions through your 
  376. Priority Level contract or purchase individual Priority Support 
  377. incidents (essentially a one-time fee for one question). If you would 
  378. like to understand more about Microsoft's paid support options, you 
  379. can call Microsoft Support Sales at (800) 936-3500 from 6:00 a.m. 
  380. to 6:00 p.m. Pacific time, Monday through Friday, excluding 
  381. holidays. Please note that technical support is not available through 
  382. this number. Microsoft Technical Support Information is also 
  383. available on the World Wide Web at 
  384.     http://www.microsoft.com/support/. 
  385.  
  386. Free Support
  387.  
  388. Newsgroups are a great place for free peer support. As time and 
  389. resources allow, Microsoft developers, program managers, support 
  390. engineers, and test engineers visit the site to collect feedback and 
  391. answer questions or correct misperceptions. There is no guarantee 
  392. that you will receive a response from Microsoft to any newsgroup 
  393. posting. 
  394.  
  395. The following newsgroups can be used to ask questions about 
  396. DCOM95: 
  397. *    comp.os.ms-windows.programmer.ole 
  398. *    microsoft.public.win32.programmer.ole
  399.  
  400. The DCOM mailing list is another good form of free peer support. 
  401. An advantage to being on a mailing list is that this is where 
  402. Microsoft will make early announcements of information on a given 
  403. topic. Again, it is peer support, and Microsoft staff will often lurk 
  404. there, but are not guaranteed to respond to any postings. 
  405.  
  406. To learn more about the DCOM mailing list, please review our 
  407. Mailing List page, 
  408.     http://www.microsoft.com/sitebuilder/resource/mail.asp.
  409.  
  410. Providing Feedback 
  411.  
  412. Please send any comments or bug reports to the DCOM mailing list. 
  413.  
  414. Resources
  415.  
  416. You can find additional information about DCOM on the COM Home 
  417. Page at http://www.microsoft.com/com/.
  418.  
  419. VII. File List
  420. --------------------
  421.  
  422. This table lists the version numbers of files distributed with 
  423. DCOM95.
  424.  
  425. asycfilt.dll     2.40.4275.1
  426. comcat.dll     5.0.1601.1
  427. compobj.dll     2.30.200.1
  428. dcom2w98.dll     2.10.35.35
  429. dllhost.exe     4.71.3328.0
  430. iprop.dll     4.0.1381.6
  431. ole2.dll     2.30.200.0
  432. ole32.dll     4.71.3328.0
  433. oleaut32.dll     2.40.4275.1
  434. olecnv32.dll     4.71.3328.0
  435. olepro32.dll     5.0.4275.1
  436. olethk32.dll     4.71.3328.0
  437. rpcltc1.dll     4.71.3328.0
  438. rpcltc5.dll     4.71.3328.0
  439. rpcltccm.dll     4.71.3328.0
  440. rpclts5.dll     4.71.3328.0
  441. rpcltscm.dll     4.71.3328.0
  442. rpcmqcl.dll     4.71.3328.0
  443. rpcmqsvr.dll     4.71.3328.0
  444. rpcns4.dll     4.71.3328.0
  445. rpcrt4.dll     4.71.3328.0
  446. rpcss.exe     4.71.3328.0
  447. secur32.dll      4.10.0.2177
  448. stdole2.tlb      2.40.4275.1
  449. stdole32.tlb     2.10.3027.1
  450. storage.dll      2.30.200.0
  451.  
  452. This table lists the version numbers of files distributed with 
  453. DCM95CFG.
  454.  
  455. dcomcnfg.exe     5.00.1603.1
  456. ciscnfg.exe      4.71.2618.0
  457.